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DETAILED ACTION 

1. This communication is responsive to amendment filed 04/24/2007 to the original 
application filed 12/30/2003. This action is made Final. 

A. Claims 1-28 are pending in the application. 

B. Claims 21-23 were amended. 

Claim Objection 

2. Claims 1-20 are objected of the following informalities: 

As to claims 1, a "system" is being recited; however, as disclosed by the 
specification, a system tends to be a computer program. The Examiner suggests 
changing to read, u a system stored on a tangible computer-readable medium for enabling 
interoperability between two graphics technologies. 

As such, claims 2-11 are objected as incorporating the deficiencies of a claim 
upon which it depends. Appropriate correction is required. 

As to claims 12, a "computer-readable medium" is being recited; however, as 
according to the specification sections, it intends the "medium" to include signals and/or 
a carrier wave. The Examiner suggests changing it to read "a tangible computer- 
readable medium storage encoded with instructions" and excluding the reference from 
the specification in regards to the wave or carrier signal. 
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As such, claims 12-20 are objected as incorporating the deficiencies of a claim 
upon which it depends. Appropriate correction is required. 



Claim Rejections - 35 CISC § 102 



3. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 
that form the basis for the rejections under this section made in this Office action: 

A person shall be entitled to a patent unless - 

(e) the invention was described in a patent granted on an application for patent by another filed 
in the United States before the invention thereof by the applicant for patent, or on an 
international application by another who has fulfilled the requirements of paragraphs (1), (2), 
and (4) of section 371(c) of this title before the invention thereof by the applicant for patent. 



4. Claims 1-6, 8-13 and 15-28 are rejected under 35 U.S.C. 102(c) as being 
anticipated by Gershony et al. (US Patent 6,549,218), hereinafter "Gershony". 

The Examiner has pointed out particular references contained in the prior 
arts of record in the body of this action for the convenience of the Applicant. 
Although the specified citations are representation of the teachings in the art 
and are applied to the specific limitations within the individual claim, other 
passages and figures may apply as well. The Applicant should consider the 
entire prior art as applicable as to the limitations of the claims. It is 
respectfully requested from the Applicant, in preparing the response, to 
consider fully the entire references as potentially teaching all or part of the 
claimed invention, as well as the context of the passage as taught by the prior 
arts or disclosed by the Examiner. 

As claim 1, Gershony teaches a system for enabling interoperability between two 
graphics technologies (col. 2, lines 44-55), comprising: 
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a first graphics system configured to render window content in a first mode (fig. 3, label 
350; col. 8, lines 13-15) the first graphics system being further configured to reference a 
first type of window using a token associated with an instance of the first type of window 
(fig. 3, label 340; col. 7, lines 60-64); 

a second graphics system configured to render windows in a second mode (fig, 3, label 
380; col. 8, lines 24-26), the second graphics system being further configured to reference 
a second type of window without a need for the token used by the first graphics system 
(fig. 3, label 340; col. 7, lines 60-64, that if the window is redirected it will not utilize the 
same token as depicted for the first window, to ensure the window is redirected); 
and an interoperability component configured to cause a dummy token to be created for 
an instance of a window of the second type (fig. 3, label 320; col 6, lines 61-65; col. 7, 
lines 33-41; col. 6, lines 14-15; col. 8, lines 52-58, that using "MICROSOFT 

4 

I 

WINDOWS" to create window "CreateWindowEX ()", using known "Microsoft- 
Component Object Model (COM) to call functions "Microsoft Windows GetDCoO" with 
a NULL window handle as a parameter and "CreateCompatiblcBitmapO" to create a 
dummy (blank) Window bitmap in memory, which is compatible with (e.g., has the same 
color depth as) the screen device context and to call "ViewObject2::Draw () to draw 
(perform) a graphics related action to enhance). 

As claim 2, Gershony further teaches an application program including a first 
window and a second window (col. 1 , lines 34-37), the first window being of the first 
type and the second window being of the second type (col. 2, lines 47-49). 
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As claim 3, Gershony further teaches the first mode comprises a compositional 
mode of graphics technology (col. 8, lines 24-28, that by applying special effects, is 
accomplished in the compositional mode). 

As claim 4, Gershony further teaches the second mode comprises an immediate 
mode of graphics technology (col. 8, lines 13-17, that by sending the windows to the 
buffer is immediate mode). 

As claim 5, Gershony further teaches the token comprises a window handle (fig. 
4, label 410; col. 7, lines 14-17; col. 8, lines 51-54). 

As claim 6, Gershony further teaches the second graphics system is configured to 
create a mapping from the token to a node in an internal construct used by the second 
graphics system to manage windows of the second type (fig. 2, label 250; col. 6, lines 67; 
col. 7, lines 1-12). 

As claim 8, Gershony further teaches the second graphics system is further 
configured to create a render target for receiving rendered window content (col. 6, lines 
61-67; col. 7, lines 1-13). 

As claim 9, Gershony further teaches the render target resides in system memory 
(fig. 1, label 22; col. 6, lines 61-67). 



I 

f 
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As claim 10, Gershony further teaches the render target resides in video memory 
(fig. 1, labels 22, 47 and 48; col, 6, lines 61-67; col. 7, linel, that there must be video 
memory as described as known before and image (target) can be sent to the display 
monitor, it must be buffered to an area of video memory). 

♦ 

As claim 11, Gershony further teaches the render target records rendering 
commands generated for windows of the second type and that are played back during 
composition to generate display output (col. 6, lines 61-67; col. 7, lines 1-13; col. 8, lines 
13-29, that by applying the special effects to the window the final result will be displayed 
(played back)). 

* 

As claim 12, Gershony teaches a computer-readable medium (fig. 1, label 32) 
having computer executable components (col. 4, lines 65-67; col. 5, lines 1-2) for 
enabling interoperability between two graphics technologies (col. 2, lines 44-55), 
comprising: 

an interoperability component that interfaces with an application program (col. 2, line 67; 
col. 3, lines 1-4), the application program including a first window and a second window 
(col. 1, lines 34-37), the first window being compatible with a first graphics system that 
uses tokens to reference windows (fig. 3, labels 340 and 350; col. 7, lines 60-64; col. 8, 
lines 13-15), the second window being compatible with a second graphics system that 
does not rely on the tokens (fig. 3, label 340; col. 7, lines 60-64, that if the window is 
redirected it will not utilize the same token as depicted for the first window, to ensure the 
window is redirected); 
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and a mock token associated with the second window, the mock token to indicate that 
the second window is compatible with the second graphics system (fig. 3, label 320; col. 
6, lines 61-65; col. 7, lines 33-41; col. 6, lines 14-15; col. 8, lines 52-58, that using 
"MICROSOFT WINDOWS" to create window "CreateWindowEX ()", using known 
"Microsoft Component Object Model (COM) to call functions "Microsoft Windows 
GetDCo()" with a NULL window handle as a parameter and 
"CreateCompatibleBitmapO" to create a dummy (blank/mock) Window bitmap in 
memory, which is compatible with (e.g., has the same color depth as) the screen device 
context and to call "ViewObject2::Draw () to draw (perform) a graphics related action to 
enhance). 

As claim 13, Gershony further teaches a mapping, maintained by the second 
graphics system, from the mock token to a node in an internal construct used by the 
second graphics system to manage the second window (col. 9, lines 45-5 1 , that a data 
structure will contain mapping linking the mock token to the node and is a key module to 
managing the display of windows). 

As claim 15, Gershony further teaches the second graphics system is further 
configured to create a render target for receiving rendered window content (col. 6, lines 
61-67; col. 7, lines 1-13). 

As claim 16, Gershony further teaches the render target comprises a software * 
render target (fig. 1, label 22; col. 6, lines 61-67; col. 7, line 1). 
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* 

As claim 17, Gershony further teaches the render target comprises a hardware 
render target (fig. 1, labels 22, 47 and 48; col. 6, lines 61-67; col. 7, linel, that there must 
be video memory as described as known before and image (target) can be sent to the 
display monitor, it must be buffered to an area of video memory). 

As claim 18, Gershony further teaches the render target records rendering 
commands generated for the second window and that are played back during composition 
to generate display output (col. 6, lines 61-67; col. 7, lines 1-13; col. 8, lines 13-29, that 
by applying the special effects to the window the final result will be displayed (played 
back)). 

As claim 19, Gershony further teaches the mock token is associated with a device 
context associated with the second window (col. 2, lines 11-16). 

As claim 20, Gershony further teaches the device context comprises a null device 
context (col. 8, lines 51-53, lines 66-67; col, 9, lines 1-8, that if the function fails, the 
return value is null, indicating an error or an invalid HWND parameter). 

As claim 21 (Currently Amended), Gershony teaches a computer-implemented 
method (fig. 1, labels 36, 37) for enabling interoperability between two graphics 
technologies (col. 2, lines 44-55), comprising: 
receiving a request to create a new window (col. 2; lines 1 1-16); 
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determining if the new window is of a type associated with an alternative graphics system 
(fig. 3, label 340; col. 7, lines 62-64); 

if so, creating a dummy token for the new window (fig. 3, label 320; col. 6, lines 61-65; 
col. 7, lines 33-41; col. 6, lines 14, 15; col. 8, lines 52-58, that using "MICROSOFT 
WINDOWS" to create window "CreateWindowEX ()" after that using known 
"Microsoft Component Object Model (COM) to call functions "Microsoft Windows 
GetDCo()" with a NULL window handle as a parameter to create a blank (dummy) 
window bitmap in memory); 

creating a new visual to be created in connection with the new window, the visual being a 
construct associated with the alternative graphics system (col. 8, lines 26-34; calling 
function "CreateCompatibleBitmap() ,, to make a dummy (blank) Window bitmap in . 
memory, which is compatible with (e.g., has the same color depth as) the screen device 
context and calling "ViewObject2::Draw () to draw (perform) a graphics related action to 
enhance); 

and associating the dummy token with the new visual (fig. 3, label 340; col. 7, lines 60- 
64, that if the window is redirected it will not utilize the same token as depicted for the 
first window, to ensure the window is redirected). 

* 

As claim 22 (Currently Amended), Gershony further teaches if the new window 
is not of the type associated with the alternative graphics system, rendering the window 
in accordance with a the conventional graphics system (fig. 3, labels 350, 360, 370; col. 
8, lines 13-19). 
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As claim 23 (Currently Amended), Gershony further teaches receiving an 
instruction to render display content to the new window referenced by the dummy token 
(col. 3, lines 8-12), looking up the new visual based on the association between the 
dummy token and the new visual (col. 8, lines 43-45, that applying visual effects, is only 
accomplished by reading/referencing the tokens), and rendering the display content to the 
new visual (fig. 3, labels 350, 360, 370). 

As claim 24, Gershony further teaches rendering the display content to the new 
visual (fig. 3, labels 350, 360, 370) further comprises issuing rendering commands to a 
render target associated with the new visual (col. 3, lines 8-12). 

As claim 25, Gershony further teaches the render target comprises a software 
render target (fig. 1, label 22; col. 6, lines 61-67; col. 7, line 1). 

As claim 26, Gershony further teaches the render target comprises a hardware 
render target (fig. 1, labels 22, 47 and 48; col. 6, lines 61-67; col. 7, linel, that there must 
be video memory as described as known before and image (target) can be sent to the 
display monitor, it must be buffered to an area of video memory). 

As claim 27, Gershony further teaches the render target records rendering 
commands generated for the new window that are played back during composition to 
generate display output (col. 6, lines 61-67; col. 7, lines 1-13; col. 8, lines 13-29, that by 
applying the special effects to the window the final result will be displayed (played 
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back)). 

As claim 28, Gershony further teaches a computer-readable medium encoded 
with computer-executable instructions for performing the method of claim 21 (fig. 1 , 
label 36; col. 5, lines 3-7). 



Claim Rejections - 35 (JSC §103 

5. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in section 102 of this 
title, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a 
whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said 
subject matter pertains. Patentability shall not be negatived by the manner in which the invention was made. 

6, Claims 7 and 14 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Gershony in view of Lin ct al. (US Patent 6,941,521), hereinafter "Lin". 

As claim 7 and 14, Gershony the internal construct comprises a visual tree, and 
the node comprises a visual. 

However, Lin teaches the internal construct comprises a visual tree, and the node 
comprises a visual (col. 3, lines 63-67; col. 4, lines 1-10). Therefore, it would have been 
obvious to one ordinary skill in the art the time the invention to modify Gershony by 
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having the internal construct comprises a visual tree, and the node comprises a visual as 

» 

taught by Lin in order to describe the structure of visuals presented on the node (display 
device). 

1 

Response to Arguments 

7. Applicant's arguments filed 04/24/2007 have been fully considered but they 
are not persuasive. Therefore, rejected to claims 1-28 is maintained. 

a. Applicant argues in paragraph that Gershony fails to teach or suggest, as 
recited in claim 1 , "a second graphics system configured to reference a second type of 
window without a need for the token used by the first graphics system". 

In response, Examiner respectfully submits and is not persuaded. Gershony 
directly teaches "a second graphics system configured to render windows in a second 
mode (fig. 3, label 380; col. 8, lines 24-26), the second graphics system being further 
configured to reference a second type of window without a need for the token used by the 
first graphics system (fig. 3, label 340; col. 7, lines 60-64, that if the window is redirected 
it will not utilize the same token as depicted for the first window, to ensure the window is 
redirected). Thus, as known in the art, if the same token was used for both the first and 
second graphic system, the windows could not be redirected to ensure compatibility. 

b. Applicant argues in paragraph that the creation of a "dummy token," but 
Gershony does not disclose and the Examiner does not show anything in Gershony 
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analogous to a "dummy token. 11 In one or more implementations deseribed in the 
application, the "null device context" is an example of the "dummy token". 

In response, Examiner respectfully submits and is not persuaded. Gershony teaches an 
interoperability component configured to cause a dummy token to be created for an 
instance of a window of the second type (fig. 3, label 320; col. 6, lines 61-65; col. 7, lines 
33-41; col. 6, lines 14-15; col. 8, lines 52-58, that using "MICROSOFT WINDOWS" to 
create window "CreateWindowEX ()" using known "Microsoft Component Object 
Model (COM) to call functions "Microsoft Windows GetDCoO" with a NULL window 
handle as a parameter and "CreateCompatibleBitmapO" to create a dummy (blank) 
Window bitmap in memory, which is compatible with (e.g.,. has the same color depth as) 
the screen device context and to call "ViewObject2::Draw () to draw (perform) a graphics 
related action to enhance). Thus it is further known in the art that a dummy/mock token 
must be created to redirect the window ensuring interoperability between windows and is 
only temporary in nature. 

c. Applicant argues in paragraph that a dummy token (e.g. null device context) is 
used to provide interoperability with the first and second graphics systems. Gershony 
does not disclose the use of a null device context used to facilitate interoperability 
between two graphics systems. In fact, Gershony discloses that the device context is used 
to read a style bit for both types of windows. 
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In response, Examiner respectfully submits and is not persuaded. Gershony 
discloses and also known in the art that using "MICROSOFT WINDOWS" to create 
window "CreateWindowEX ()", using known "Microsoft Component Object Model 
(COM) to call functions "Microsoft Windows GetDCoO" with a NULL window handle 
as a parameter and "CreateCompatibleBitmapO" to create a dummy (blank) Window 
bitmap in memory, which is compatible with (e.g., has the same color depth as) the 
screen device context and to call "ViewObject2::Draw () to draw (perform) a graphics 
related action to enhance). The creation of the bitmap in memory is a established by the 
style bit (token) which is set to redirect the window to the device context. 

d. Applicant argues in paragraph that the Examiner contends that Gershony's 
"style bit" is analogous to the "token" of this claim. If that is so, then Gershony fails to 
teach or suggest, as recited in claim 12, "the second window being compatible with a 
second graphics system that does not rely on the tokens". 

In response, Examiner respectfully submits and is not persuaded. That the 
style bit described by Gershony is used to redirect a window to the bitmap buffer. It is 
further known in the art that a style bit is used to categorize and perform a behavior such 

i 

as a token whether dummy or mock token is used. That redirecting a window is a 
behavior accomplished by a dummy/mock token or a style bit. Furthermore a window 
would not need a token if it is compatible with the graphics system, which in turn would 
not rely upon a token or style bit. 
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e Applicant argues in paragraph that recites the creation of a "mock token/' but 
Gershony does not. In one or more implementations described in the Application, the 
"null device context" is an example of the "mock token". 

In response, Examiner respectfully submits and is not persuaded. Gershony 
discloses and also known in the art that using "MICROSOFT WINDOWS" to create 
window "CreateWindowEX ()", using known "Microsoft Component Object Model 
(COM) to call functions "Microsoft Windows GetDCo()" with a NULL window handle 
as a parameter and "CreateCompatibleBitmapO" to create a dummy (blank) Window 
bitmap in memory, which is compatible with (e.g., has the same color depth as) the 
screen device context and to call "ViewObject2::Draw () to draw (perform) a graphics 
related action to enhance). Therefore the style bit uses the same principle/concept as a 
token and causes a window to be redirected as known in the art. 

f. Applicant argues in paragraph [0023] that Gershony does not disclose the use 
of a null device context used to facilitate interoperability between two graphics systems. 

In response, Examiner respectfully submits and is not persuaded. It is well 
known in the art that a null device context is used as a parameter as a dummy or mock 
token and is imperative in the redirection of windows to ensure interoperability between 
two graphic systems. Furthermore there is no difference between a mock or dummy 
token, both meaning the same thing and being a synonym of each other. 



Application/Control Number: 10/749,125 Page 16 

Art Unit: 2179 

g, Applicant argues in paragraph [0026] that claim 21 recites the creation of a 
"dummy token," but Gershony does not. In one or more implementations described in the 
application, the "null device context" is an example of the "dummy token". 

In response, Examiner respectfully submits and is not persuaded. Gershony 
discloses and also known in the art that using "MICROSOFT WINDOWS" to create 
window "CreateWindowEX ()", using known "Microsoft Component Object Model 
(COM) to call functions "Microsoft Windows GetDCo()" with a NULL window handle 
as a parameter and "CreateCompatibleBitmapO" to create a dummy (blank) Window 
bitmap in memory, which is compatible with (e.g., has the same color depth as) the 
screen device context and to call "ViewObject2::Draw () to draw (perform) a graphics 
related action to enhance). Furthermore there is no difference between a mock or dummy 
token, both meaning the same thing and being a synonym of each other. 

h. Applicant argues in paragraph that a dummy token (e.g., null device context) 
is simply used to provide interoperability with the conventional and alternative graphics 
systems. Gershony does not disclose the use of a null device context used to facilitate 
interoperability between two graphics systems. In fact, Gershony discloses that the device 
context is used to read a style bit for both types of windows. 

In response, Examiner respectfully submits and is not persuaded. Gershony 
discloses and also known in the art that using "MICROSOFT WINDOWS" to create 
window "CreateWindowEX ()", using known "Microsoft Component Object Model 
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(COM) to call functions "Microsoft Windows GetDCo()" with a NULL window handle 

« 

as a parameter and "CreateCompatibleBitmapO" to create a dummy (blank) Window 
bitmap in memory, which is compatible with (e.g., has the same color depth as) the 

i 

screen device context and to call "ViewObject2::Draw () to draw (perform) a graphics 
related action to enhance). Thus the use of a null device context is used the same as a 
style bit, mock or dummy token, because it is a statement that is temporary in nature to 
ensure compatibility between systems. 

Conclusion 



8. THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of 
time policy as set forth in 37 CFR 1 .136(a). A shortened statutory period for reply to this 
final action is set to expire THREE MONTHS from the mailing date of this action. In the 
event a first reply is filed within TWO MONTHS of the mailing date of this final action 
and the advisory.action is not mailed until after the end of the THREE-MONTH 
shortened statutory period, then the shortened statutory period will expire on the date the 
advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be 
calculated from the mailing date of the advisory action. In no event, however, will the 
statutory period for reply expire later than SIX MONTHS from the mailing date of this 
final action. 

9. Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Thuy Osberg whose telephone number is 571-270-1258. 
The examiner can normally be reached on Monday-Friday (8:30AM-5:00PM). 
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If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Weilun Lo can be reached on 571-272-4847. The fax phone number for the 
organization where this application or proceeding is assigned is 571-273-8300. 

Information regarding the status of an application may be obtained from the . 
Patent Application Information Retrieval (PAIR) system. Status information for 
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